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Pield of t H^ Invention 

The invention relates to a protocol for message 
comnrunication between an access network and a local 
5 exchange. 
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Background of the Invention 

Digital loop carriers (DLCs) provide stibscribers in a 
carrier serving area with at least one of the following: 
voice-grade service, digital data service (e.g., up to 64 
5 kilobits per second (kbps) , digital subscriber lines 
(DSLs) for integrated digital services networks (ISDNs) 
and a number of two- wire voice -grade special serv^ices. A 
DLC can be a stand-alone or universal DLC (UDIX!) , or 
integrated into a local serving switch to create an 
10 integrated DLC (IDLC) . A DLC conqprises a local digital 
switch (IiDS) , a digital transmission facility (DTP) and a 
remote digital terminal (RDT) such as a SLC«96 remote 
terminal available from AT&T, Parsippany, New Jersey, 
Conventional metallic pair loop designs are often used on 
IS the subscriber side of the RDT, although other, links such 
as fixed wireless links (FWLs) can be used. The LDS 
provides at least one DSl digital carrier (i.e., a North 
American standard 1.544 megabit/sec (Mbps) Tl or an 
International Telegraph and Telephone Consultative 
20 Committee (CCITT) standard -2 . 048 Mbps El) to the RDT, The 
DSl can be transported on metallic pairs or a fiber pair, 
for example. 

A number of standards have been developed for DLCs 
such as the TR-303 standard described in the Technical 
25 Reference TR-NWT-000303 and related documents pxiblished by 
Bell Communications Research, Inc., Morristown, New 
Jersey, and the V5 standard promulgated by the European 
Telecommunications Stsmdards Institute (ETSI) . The TR-303 
standard describes a generic interface between a RDT 12 
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and a LDS 14 in an IDLC 10, as shown in Pig. 1. The LDS 
14 con^rises switch stages 16 and an integrated digital 
terminal (IDT) 18. Operating systems (OSs) 24 can be 
connected to the IDT 18. The IDLC system 10 further 
5 comprises a digital signal cross-connect 20 and an office 
repeater bay 22. TR-303 is also applicable to non- 
integrated systems, that is, XJDLC systems using the same 
RDT 12 . DDLCs are typically installed in analog central 
offices (C30s) and then later integrated by replacing the 
10 analog switch with a LDS 14 and the COT with a direct 
digital interface to the LDS . 

According to the TR-303 standard, the physical layer 
of the IDLC interface is based on DSl rate modularity. A 
DSl uses the Extended Super Frame (ESF) format which 
IS employs the channel derived from the 193rd bit of a DSl 
frame for a number of functions such as synchronizaticai 
and error detection, and a derived 4 kbps channel for 
performance report messages between an RDT 12 and an LDS 
14 or alarm codes when preempted. A separate DSO data 
20 link called the Embedded Operations Channel (EOC) is used 
for transmitting operations messages between the RDT 12 
and the LDS 14 and between the RDT and operating systems 
(OSs) . The EOC is based on LAPD or Link Access protocol on 
the D- channel for ISDN. 
25 The generic IDLC interface described in TR-303 

supports two different call processing techniques. The 
first technique is hybrid signaling (i.e., sixteen state 
robbed-bit signaling or in-slot signaling) wherein ABO) 
codes are transmitted for call supervision (e.g., on-hook 
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and off -hook detection) while a time slot is assigned to 
the line unit. Per-call time slot assignment is 
accomplished^ over a €4 kbps data link channel (i.e., a DSO 
channel) referred to as the Time Slot Management Channel 
5 (TMC) which carries messages bet%»een the LDS and RDT. 
These messages are used to create and destroy time slot 
assignments between line units and DSOs on a per-call 
basis. The second call processing technique is out-of- 
band signaling and consists solely of a 64 kbps data link 
10 channel referred to as the Common Signaling Channel (CSC) . 
The CSC carries messages for making time slot assignments 
and for call supervision. Both the TMC and the CSC are 
based on the LAPD protocol that is used on ISDN p- 
channels. The LDS 14 in a generic IDLC 10 under TR-303 
15 preferably accommodates both call processing techniques to 
enable connection with different RDTs 12 which may use 
either TMC or CSC signaling, but need not do so 
simultaneously for any one RDT. m both types of 
signaling, that is, TMC and CSC, time slot assignment is 
20 accomplished at the LDS 14. 

With reference to Pig. 2, the RDT 12 is one of a 
number of different types of access networks (ANs) 26, and 
the LDS 14 is more generically described as a local 
exchange (LE) 28. The ETSI developed the V5 protocol 
25 (i.e., V5.1 and V5.2) for a link 30 between an AN 26 and a 
LE 28, which shall hereinafter be referred to as an AN-LE 
link 30. The V.5 protocol is substantially equivalent to 
TR-303; therefore, the TR-303. V.5 protocol and similar 
protocols for AN-LE links are disadvantageous for a number 
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Of the same reasons. First, these protocols require an AN 
(e.g.; a radio base unit (RBU) in a FWL) to report all 
physical signals collected at customer premises equipment 
(CPE) 32 (e.g., a line unit connected to a RDT 12) to the 
LE 28. The LE 28 then analyzes the signals to determine 
the type of service to offer the subscriber. Thus, air 
channels in a FWL are being used for the transmission of 
redundant data that does not generate revenue. Second, 
these protocols do not provide call processing in a number 
of situations such as when a CPE 32 goes off -hook and no 
air channel or DSO is available. In such a case, the ^aH 
26 rejects the call in accordance with these protocols. 
These protocols are not error -tolerant and do not provide 
self -alignment functions. In addition, these protocols do 
not permit priorities to be assigned to calls (e.g., 
emergency calls using •Sli") . The protocols generally use 
one or more selected links between a AN 26 and a LE 28 for 
signaling. Thus, when one of these links 30 is not 
functional, some of the control communication channels may 
be lost because the protocol does not provide for transfer 
of calls to another link that is operational. 
Alternatively, some calls must be torn dovm in order to 
allow for transfer of control to other links 30. Finally, 
these protocols require the LE to transmit time slot or 
25 channel assignment information regardless of whether it is 
used by the AN. 



15 



20 



wo 98/09448 



«. pciyus».r/i525» 

- 6 - 



Summary of the Invention 

In accordance with the present invention, a protocol 
is provided i for links between an AN and an I4B which 
overcomes disadvantages associated with existing protocols 
5 and realizes a number of advantages. The protocol 
provides for common channel signaling on all of the AN-LE 
links and the transfer of calls from a failed link to an 
operational link without reinitializatiotx of links 
following a switchover protocol, and additional 
10 administrative functions. Further, the protocol of the 
present invention conserves bandwidth by permitting the 
CPE to interpret physical signals and to send processed 
results to an AN, and by eliminating the need for the LE 
to send channel assignment data to the AN. The AN assigns 
15 channels on one or more AN-LE links . 

In accordance with another aspect of the present 
invention, the AN-LE interface protocol provides for call 
processing in a number of glare conditions vrtiich arise in 
a telecommunications system having multiple points of 
control along the path of a call (e.g., an AN that assigns 
channels on the AN-LE link) . Examples of these glare 
conditions include a CPE placing an outgoing call when the 
NIU is sending it an incoming call, or the NIU placing an 
incoming call to the CPE when the RBU is sending it an 
25 outgoing call. 

In accordance with another aspect of the present 
invention, the protocol implements a self -aligning, error- 
tolerant link layer which allows for detection of link 
failure by either the AN or LE end point, notification of 
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the other end point, termination of multiple frame 
operation and transfer of calls and control signaling from 
the failed aink to other operational links. The link 
layer also provides for notifying end points of 
5 misalignment conditions and for corrective procedures. 

pylef DeaeriTatiof T Drawings 

These and other features and advantages of the 
present invention will be more readily apprehended from 
10 the following detailed description when read in connection 
with the appended drawings, which form a part of this 
original disclosure, and wherein: 

Fig. 1 is a block diagram of a conventional 
integrated digital loop carrier; 
15 Pig. 2 is a block diagram of a conventional 

telecommunications access system; 

Fig. 3 is a block diagram of an exemplary 
telecommunications access system for implementing a 
multilink AN-IiE interface protocol in accordance with an 
20 embodiment of the present invention; 

Pig. 4 is a block diagram of a trunk board for use in 
the local exchange of the telecommunications access system 

depicted in Fig- 3; 

Pig. 5 is a schematic block diagram illustrating the 
25 layers of network processing associated with an AN and a 
LE that employ a multilink AN-LE interface protocol in 
accordance with an embodiment of the present invention; 

Figs. 6-20 are flow charts illustrating respective 
sequences of call processing operations performed by the 
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AN and the LE in accordance with an embodiment of the 
present invention; 

Pigs. 21-29 are flow charts illustrating sequences of 
operations performed by the AN and the LE during link 
5 layer initialization, multiframe operation, link failure 
and link recovery states; and 

Figs. 30-35 are schematic diagrams of illustrating 
the processing of exemplary packets transmitted between 
the AN and the LE in accordance with an embodiment of the 
XO present invention. 

Detailed Description of the Prefei-r-f^d E^nbodilTl>.r.^ 

The multilink AN-LE interface protocol of the present 
invention is preferably used for signaling on two or more 
15 AN-LE links 30 (Pig. 2). For illustrative purposes, the AN 
26 is a radio base unit (RBU) , the LB 28 is a network 
interface unit (NIU) , an AN-LE link 30 is an El, and the 
CPE 32 is located in a FWL. The reference numerals 26 and 
28 shall hereinafter correspond to the RED amd NIU, 
respectively, as shown in Fig. 3. It is to be understood, 
however, that the AN-LE interface protocol of the present 
invention can be used with substantially any type of AN-LE 
link 30 and with sijbstantially any type of CPE 32, AN 26 
and LE 28. 

With reference to Fig. 3, the RBU 26 can be, for 
exainple, a Lockheed-Martin RBU provided for the CD2000 
line of FWL products available from Granger 
Telecommunications Systems, Ltd., United Kingdom. The RBU 
is configured for connection to four Els. Pour AN-LE 
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links 30 shall therefore be described as connecting the AM 
26 and the LE 28 for illustrative ptirposes. 

The NTU 28 preferably corqprises one or more master 
control units (MCOs) 34 and one or more peripheral boards 
5 such as the boards described in U.S. Patent No. 5,291,479, 
which issued March 1, 1994 to Paramarz Vaziri, Brian 
Bolon, Brent E. Bryson, John Emerick and is incorporated 
herein by reference. For example, the NIU 28 can contprise 
a digital board 36 connected to the PSTN, and trunk boards 
10 38a and 38b. The trunk boards 38a and 38b can each, be 
connected to the RBU 26 by two Els. It is to be understood 
that an MOT 34 can be connected to different numbers and 
different types of peripheral boards, as well as to other 
MOTS. 

15 The MCU 34 and the peripheral boaixls 36a, 36b and 38 

are preferably connected by a plurality of pulse code 
modulated (PCM) highways indicated generally at 40. For 
exanple, six PCM highways can be provided to transmit data 
among the MOT 34 and the peripheral boards, each PCM 

20 highway having an aggregate data rate of 2.048 Mbps and 32 
time division multiplexed (TDM) 64 kbps channels . Thus , as 
many as 192 ports can have PCM highway access without 
blocking any port activity. Seventh and eighth dedicated 
PCM highways are preferably also provided for service 

25 circuits and internal system communication, respectively. 
The seventh and eighth PCM highways preferably use the 
high-level data link control (HDIiC) developed by the 
International Standards Organization to establish a 
master/slave relationship between the MOT and the 
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peripheral boards as described in U.S. Patent No. 
5,291,479. A time slot interchange (TSI) 42 is provided 
on the MCU 34 which allows the MCD to route calls via the 
192 ports and to connect the ports to local services . 
5 With reference to Pig. 4, a trunk board 38 is shown 

which comprises circuitry for processing a pliarality of 
trunk lines such as two Els 44 and 46. A, backplane 
interface 48 is provided for connecting the trunk board to 
the PCM highrays 40. The baclq>lane interface 48 conprises 
lb HDLC control for the seventh and eighth dedicated PCM 
highways and TSI control for switching data from the Els 
onto one of the 192 channels or for receiving data packets 
from a channel that are addressed to the trunk board. A 
main control circuit 50 on the trunk board conprises a 
15 board processor 45, read-only and random access memories 
47 and 49 (i.e., a ROM and a RAM), serial ports 51 and 
program code for communicating with the MCU 34 via HDLC 
control and for operating trunk board components. 
Further, the trunk board 38 comprises HDLC controllers 52a 
20 and 52b, optional digital signal processors (DSP) 54a and 
54b and El interface units 56a and S6b for each of the two 
Els, respectively. Each HDLC controller 52 is prograiraned 
to process signaling between the MIU 28 and the RBU 26 on 
that particular El in accordance with the protocol of the 
25 present invention. Each DSP 54 is programmed to provide 
tone detection and generation and echo cancellation, among 
other functions. Each El interface xmit 56 provides a 
physical interface for with an El, as well as clocking, 
protection. 
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The AN (e.g., HBU) 26 and the LB (e.g., NIU) 28 will 
now be described with reference to three layers in the 
Open Systems Interconnection (OSI) model network 
architectxire designed by the International Standards 
Organization (ISO) . First, a physical layer 58 such as an 
RS-232 wireline or other physical connection is provided 
between the AN 26 and the LE 28, as shown in Fig. 5. 
Second, a link layer 60 is provided to ensure frames of 
data are reliably transmitted on the pfij^ie4l~' layer 58 
between the AN 26 and the LE 28, for example. Finally, an 
application layer 62 is provided for call processing. 

The application layer of the AN-LE interface 
protocol of the present invention will now be described 
with reference to Figs. 6-20. The flow charts in Figs. 
6-20 illustrate call processing for a number • of events, 
including an outgoing call from a CPE 32 to the NIU 28 
(Pig. 6), an incoming call from the PSTN to a CPE 32 
(Pig. 7), call tear-down upon receipt of an on-hook 
signal from a CPE 32 (Fig. 8) , call tear-down upon 
release of a high traffic, low priority (HTLP) call by 
the RBU 26 (Pig. 9) , call tear-down upon detection of a 
lost air channel by the- RED 26- (Fig. 10), call tear-down 
initiated by the NIU 28 (Fig. 11), change of call type 
(Fig. 12) or call priority (Fig. 13), hook flash (Pig. 
25 14), an incoming call from a pay telephone (Fig. 15), 
channel reassignment to another on the AN-LE link 30 
(Fig. 16), a number of glare conditions (Figs. 17-19), 
and call rejection at a CPE 32 (Pig. 20). 
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As shown in Pig. 6, the RBU 26 receives an 
indication that a CPS 32 has gone off-hook, as indicated 
in blocks ^0 and 72. The RBU 26 is programmed to 
determine whether or not the CPE 32 or subscriber unit 
32 is authorized to access the network via the RBU 26 and 
the NIU 28, and rejects the call if the CPE 32 28 is not 
authorized (blocks 74 and 76) . a call rejection signal 
is transmitted from the RBU 26 to the CPE 32 (block 78) 
The CPE 32 subsequently undergoes the procedure 
illustrated in Pig. 20 for call termination or rejection. 
If subscriber unit 32 access is authorized, the RBU 26 
determines whether or not any channels on an AN-LB link 
30 are available (block 80) . The AN-LE interface 
protocol of the present invention assumes a generic 
15 interface between the RBU and the CPE. By way of 
example, the RBU 26 can transmit a wait-for-dial tone 
command to the CPE 32 if no channels are available . 
(blocks 82 and 84) . If a channel does not become 
available within a predetermined period of time, the call 
20 is rejected, as indicated by blocks 83 and 85. If 
channels are available on an AN-LE link 30, the RBU 26 is 
programmed to commence processing an outgoing call (block 
86) by transmitting a CMD_OTG_CALL_SETUP command to the 
NIU 28 (block 88) . The CMD_OTG_CALL_SETUP command 
25 provides the NIU 28 with a time slot on an AN-LE link 30 
that is to be used for the outgoing call, the 
subscriber's identification number, and other 
information. Alternatively, the AN-LE link 30 can be a 
serial RS-232 connection. 
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In accordance with the present invention, the RBU 26 
does not forward an indication that the CPE 32 has gone 
off -hook to the NIU 28. The CPE 32 determines the off- 
hook condition itself and then reports the condition to 
the RBU 26. This is in contrast with existing AN-LE link 
protocols which require the transmission of physical 
signals from the CPE 32 to a local exchange 28 for 
processing to determine the service that is to be 
provided, thereby placing redxmdant, non-revenue 
generating data on the communication linlcs between the. 
CPE 32 and the AN 26 and between the AN 26 and the LE 28. 

upon receipt of the CMD__OTG_CALL__SETDP command 
(block 90). the NIU 28 proceeds to process an outgoing 
call in accordance with its program code (block 92) . For 
example, the NIU 28 first determines whether - or not it 
can accept an outgoing call (block 94) . If the NIU 28 is 
unable to accept the call, it transmits a 
RSP_OTO_CAIiL_SETUP response with a failure code signal to 
the RBU 26 (block 94) . The NIU 28 then enters an idle 
state (block 96) . Upon receipt of this response signal 
(blocks 98 and 100), the RBU 26 releases the channels 
that were being reserved for the outgoing call initiated 
by the CPE 32 and otherwise clears the call (block 102) . 
The RBU 26 subsequently transmits a call rejected signal 
25 to the CPE 32 (blocks 104 and 106) . Accordingly, the CPE 
32 commences the process illustrated in Fig. 20, and the 
RBU 26 enters an idle state (block 107) . If the NIU 28 
can accept the outgoing call, it transmits a 
RSP OTG_CAIiL_SETnP response with a success code signal, 
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as indicated by the affirmative branch of decision block 
94 and block 108. Meanwhile, the RBU 2€ conunands the CPE 
32 to prepare for conanunieation on the time slot assigned 
by the RBU 26 and to stop playing all tones, as indicated 
S in blocks 110, 112, 114 and 116. 

After the NIU 28 transmits a response signal 
indicating that it is prepared to process the outgoing 
call (block 108) , the NIU 28 seizes a trunk and awaits 
receipt of dual-tone multi-frequency (DTMP) digits 
10 (blocks 118, 119 and 120) . Priority of the outgoing call 
is based on a default priority that is determined by the 
subscriber service and the DTMF digits. For example, the 
majority of the calls can be high traffic, low priority 
(HTLP) calls, except for emergency service calls such as 
15 "Sii- calls which receive the highest priority by the NIU 
28. As indicated in blocks 122 and 124, the NIU assumes 
that the call is a high priority call, unless the 
collected digits indicate otherwise. The NIU 28 

transmits a CMD_CHANGE_CALL_PRIORITY command to the RBU 
26 (block 126). Based on' the priority indicated by the 
NIU (block 128) , the RBU 26 can proceed with call tear- 
down, as described below in connection with Pig. 9, or 
continue to operate in conjunction with the CPE 32 for 
the duration of the call (blocks 130 and 132) . 
Meanwhile, the NIU 28 is in a call-in-progress state 
(block 134) . 

Incoming call processing will now be described with 
reference to Fig. 7. The NIU 28 receives a ring signal 
and determines whether or not it can accept the incoming 
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call (blocks 132, 144 and 146). If it cannot, the NIU 28 
rejects the call and enters an idle state (blocks 148 and 
150) . If the call is accepted, the NIU 28 transmits a 
CMD_INC_CALL_SETOP command to the RBU 26 (block 152) . 
The RBU 26, in turn, prepares to process an incoming call 
(blocks 154, 156 and 158). The RBU 26 transmits a 
RSP INC CALL_SBTUP response signal to the NIU 28 
indicating via one or more of its bits whether or not it 
has failed or succeeded in preparing for the incoming 
call (blocks 160 and 162) . The RBU 26 also transmits a 
ring signal to the CPE 32 (blocks 168 and 170) . Thus, in 
contrast with existing AN-LE link protocols, channel 
assignment occurs at the RBU 26 and not at the local 
exchange or NIU 28. The NIU 28 receives the 

IS RSP INC_CALL_SETUP response signal (block • 172) and 
proceeds to reject the call if the NIU fails to accept 
the incoming call (block 174, 176 and 178); otherwise, 
the NIU sets a ring-trip timer (block 180). The NltJ 28 
terminates the call in accordance with the flowchart 
20 depicted in Pig. H if a CMD_RING^TRIP command is not 
received from the RBU 26 within a predetermined period of 
time (block 182) . After the CPE 32 goes off-hook (block 
184) and notifies the RBU 26 of its off-hook condition 
(block 186), the RBU 26 transmits a CMD_RING_TRIP command 
25 to the NIU 28 (blocks 188 and 190). After the command 
signal is received, the NIU 28 processed the call in 
progress, along with the RBU 26 and CPE 32 (blocks 192, 
194 and 196) . 
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The RBU 26 responds by locating a time slot on "an! 
AN-LE link 30 for the call (block 164) . The response 
signal from *the RBU 26 is sent to the NIU 28, but not 
necessarily over the same AN-LE link over which the 
5 command was sent. Alternately, the response signal can 
be sent via a common control serial connection. llip 
RSP_INC_C3U[iL__SETUP message is sent over the Bl link on 
which the call is assigned by the RBU 26 and conqprises! 
the time slot of the call unless a fail status condition: 
10 is being transmitted. The CPE 32 is also notified, of the 
channel assignment by the RBU 26 (block 166) . 

With reference to Pig. 8, the RBU 26 determines 
whether or not the NIU 28 should be informed of an on^ 
hook condition during call termination (blocks 198, 200 
15 and 202) . The NIU 26 does not need to know about a CPE 
32 on-hook event when, for example, a CPE 32 goes on-hook 
while waiting for an air channel to make an outgoing call 
to the RBU 26. If this is not the case, the RBU 26 
generates a CMD_DROP_CALL command for the NIU 26 (block 
20 204). The NIU 28, in turn, releases the channel assigned 
by the RBU 26 (blocks 206 and 208) and generateis a 
CMD__REIiEASE_CHAN command for the RBU 26 (block 210) prior 
to entering an idle state (block 212) . The RBU 26, in 
turn, releases the air chemnel (blocks 214 and 216) and 
25 transmits a command for the CPE 32 to do the same (blocks 
216 and 220) . The RBU 26 undergoes an on-hook clean-up 
process prior to entering in an idle state (blocks 222 
and 224) along with the CPE 32 after it has released the 
air channel (block 226) . If the NIU 26 need not be 
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informed of the on-hook condition and no air channel was 
established (250). then the RBU 26 performs an on-hook 
clean-up routine before entering an idle state (blocks 
232 and 234) . 

The process for tearing-dovm a telephone call 
following a priority evaluation (block 236) by the RBU 26 
is illustrated in Fig. 9. The RBU 26 determines whether 
or not the NIU needs to be informed of the call tear-down 
process (block 238) . As stated previously, there are 
instances when the NIU 28 does not need to know about an 
on-hook event from the CPE 32, or a decision by the RBU 
26 to tear-down a call which has not yet been coordinated 
with the NIU 28. If the call has involved some form of 
handshaking with the NIU 28 (e.g., the transmission of a 
IS CMD_OTG__CAIiL_SETUP command) then the RBU 26 proceeds to 
send a CMD^DROP^CALL command to the NIU 28 (blocks 240 
and 242) . The command preferably con?)rises a field for 
indicating that the call is being dropped due to a 
priority evaluation, as opposed to am on-hook condition, 
20 for example. The NIU 28 tuidergoes a process for dropping 
the call (block 244) and svibsequently transmits a 
CMD__RELEASE_CHAN command to the RBU 26 (blocks 246 and 
248) . This command also has a field specifying the 
reason for the command, such as an on-hook condition. 
25 Upon receipt of this command, the RBU 26 proceeds to 
release the air channel (block 250) and to notify the CPE 
32 of the same (blocks 252 and 254) before undergoing ah 
on-hook clean-up process (block 256) . If the NIU 28 need 
not be informed of a call being dropped by the RBU, the 
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RBU 26 determines whether or not an air channel was 
established with the CPE 32 (block 258) . If not, the R^U 
26 treuaBinits' a call rejected signal to the CPB 32 (blocks^ 
260 and 262) before undergoing an on-hook clean-up 
process (block 264) . After the CPE 32 receives a call- 
reject comniand Or a release air channel command, it 
imdeargoes the process described below in cmmection with 
Pig. 20. 

- - Call tear-down can also result u^on detection of 
loss of a channel, as illustrated in Pig. lo. For 
example, if the CPE 32 detects loss of the radio link 
with the RBU 26 (block 268), it undergoes the process 
described in connection with Fig. 20. If the RBU 26 
detects the loss of a radio channel (block 270), it 
15 determines whether or not the NIU 28 should be informed 
(block 272). If the loss of channel occurred . while the 
CPB 32 was waiting for a channel on an AN-LE link 30 to 
make an outgoing call, then the NIU 28 need not be 
informed. Accordingly, the RBU 26 can proceed with an 
20 on-hook clean-up process (block 274). The RBU 26 
otherwise sends a CMD__DROP_CALL command (block 276) 
having bits for indicating a lost chazmel ccmdition to 
the NIU 28. The NIU 28 terminates the call (block 278) 
before transmitting a commauid to the RBU 2628 to release 
25 the channel (blocks 280 and 282) . The RBU 2628, in turn, 
undergoes the on-hook clean-up process (block 294) and 
plays tones at the CPE 32 as needed. 

As shown in Fig. ii, the NIU 28 can initiate a call 
tear-down process if, for example, it receives an on-hook 
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signal from the PSTN, or a partial dial signal, or a 
ring- trip time-out signal. The NIU 28 transmits a 
C3>1D_RELEASE_CHAN command to release the channel AN-LE on 
the link 30 (block 288) to the RBU 26 (blocks 284 and 
5 286) . The RBU 26, in turn, releases the air channel and 
notifies the CPE 32 of having done so (blocks 290 and 
292) . The CPE 32 undergoes the process described in 
connection with Pig. 70 while the RBU 26 undergoes an on- 
hook clean-up process (block 294) . 
10 With reference to Fig. 12, the NIU 28 can transmit a 

CMD_CALL_TyPE command to the RBU 26 if the NIU detects a 
data call-type tone from the PSTN or RBU (blocks 298 and 
300) . The RBU 26 proceeds to determdLne whether or not 
extra bandwidth is required based on call -type 
15 information provided in the CMD_CALL_TyPB command (block 
302) . If extra bandwidth is not required, the RBU 26 
transmits a command to the CPE 32 (blocks 304 and 306) to 
commence call processing using a 32 kbps rate, as opposed 
to a 64 kbps rate, in a E-1 based system (blocks 308 and 
20 310). It is to be understood that these bandwidths are 
for illustrative purposes only and that other bandwidths 
can be used to process different call-types in accordance 
with the present invention. If the RBU 26 determines 
that extra bandwidth is required and is available (block 
25 312) , the RBU 26 proceeds to change the call-type (block 
314) by sending a command to the CPE 32 (blocks 316 and 
318) to use a 64 kbps rate (block 320). If extra 
bandwidth is not available, the RBU 26 sets a timer 
(block 322) . If extra bandwidth is made available before 
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the timer times out (block 324) , then the RBU 26 changes 
call -type by commanding the CPE 32 to use a 64 kbps rate 
(blocks 314 i and 316) . The RBU 26 then transmits a 
RSP__CHG_CALL-TYPE response signal to the NIU 28 
5 indicating that the change of call type was successful 
(blocks 326, 328 and 330) . If the timer times out before 
the required bandwidth is available (block 332), this RBU 
26 transmits a response signal to the NIU indicating that 
the change of call type was a failure (blocks 334, 328 
10 and 330) . The RBU and the NIU proceed to process the 
call in progress (blocks 336 and 338) . 

The NIU 28 can also send a connnand to the RBU 26 to 
change the call priority, as illustrated in Pig. 15. The 
RBU 26 assumes that a call is high priority unless it is 
15 instructed otherwise by the NIU 28. The RBU 26 therefore 
responds by changing to the new priority (blocks 340 and 
342) specified in the NIU command. If the new priority 
is a lower priority (block 246) , then the RBU 26 
determines whether or not more bandwidth is desired for a 
20 different call with higher priority or whether a CPE has 
been waiting in a queue for an available air channel 
(block 346) . A call that has been placed in a queue is 
preferably considered a high priority call by default. 
If so, the RBU 26 proceeds to process call priority and 
25 to determine whether the call should be dropped (blocks 
348, 350 and 352), that is, whether or not there is a 
call in the queue or there is a call with higher priority 
requiring additional bandwidth and the current call has 
the lowest priority. if the current telephone call 
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Should be dropped, then the RBU 26 proceeds to operate in 
accordance with the procedure illustrated in Pig. 9. 

With reference to Fig. 14, the CPE 32 notifies the 
RBU 26 when a hook- flash event occurs (blocks 354 and 
5 356) . The RBU 26 decides whether or not the NIU 28 
should be informed of the event (block 358) . As stated 
previously, there are instances when the NIU 28 does not 
need to know whether a hook- flash event has occurred, 
such as when the CPE 32 hook flashes while waiting for a 

10 channel on an AN-I.E link 30 to make an outgoing call. If 
this is so, the RBU 26 discards the event (block 360) ; 
otherwise, the RBU 26 sends a CMD_HOOK__FLASH command to 
the NIU 28 (block 362) - The NIU 28 proceeds to process 
the hook-flash (blocks 364 and 366), while the NIU 28 

15 proceeds to give a dial tone to the CPE 32 that is of f - 
hook . 

With reference to Fig. 15, the NIU 28 is prograranied 
to detect a pay telephone signal transmitted from the 
PSTN (blocks 368 and 370) and to determine whether or not 

20 the RBU 26 should be informed (blocks 372 and 374). For 
example, the RBU 26 need not be informed if no channel on 
an AN-LE link 30 has been assigned by the RBU 26 for the 
incoming call from the pay telephone. If so* the NIU 28 
transmits a PAyPHONE_SIGKAL command to the RBU 26 (block 

25 376) . The RBU, in turn, forwards the PAYPHONE_SIGNAL to 
the CPE 32 (blocks 3 84 and 386) following a determination 
that the CPE 32 should be informed (blocks 378, 3 80 and 
382) . The CPE 32 need not be informed, for example, when 
no air channel has been established with the RBU 26. 
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In accordance with the present invention, the 
protocol permits the RBD 26 to perforin channel 
reassignmenti among the AN-LE links 30. With reference tb 
Pig. 16, if the NIU 28 detects a channel reassignment; 
condition such as a link failure (block 388) and 
additional control links are available between the RBU 
and NIU, the NIU transmits a C»«D__LINK_PAIL command to the 
RBU 26 (blocks 390 and 392). Alternatively, the RBU 26 
can detect a channel assignment condition such as a 
number of packets being unsuccessfully transmitted from 
the NIU 28, as described below in connection with the 
link layer 60 of the AM-LE interface protocol of the 
present invention. The RBU 26 responds by locating 
another AN-LE link channel to which the call in progress 
15 can be moved. The RBU 26 sends a command to. reassign a 
channel to the NIU 28 comprising the new time slot for 
the call on the AN-LE link (blocks 396 and 398) , as well 
as the previous time slot for the call and a link 
identification number for the previous channel. The NIU 
20 28 responds to the reassigned channel command by dropping 
the call from the previous channel and setting up the 
call on the newly assigned channel (block 400) . If the 
reassignment is successful, the NIU 28 indicates the same 
to the RBU 26 via a RSP_REASSIGN__C3IAN response signal 
25 which contains bits to indicate success (blocks 402 and 
404) . If the reassignment is not successfia, a response 
signal is sent to the RBU indicating failure (block 406) . 
If the RBU 26 receives a success response signal (blocks 
408 and 410), it continues to process the call in 
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progress (block 4X2) ; otherwise, the RBU 26 releases the 
air channel (block 414), instructs the CPE 32 to do 
likewise (blocks 416 and 418) , and begins an on-hook 
clean-up process (block 420) . 
5 The AN-LE interface protocol of the present 

invention is advantageous because it allows call flow 
exceptions to be processed, whereas the calls would be 
rejected or terminated using existing protocols. A call 
flow exception is a condition in which a call is 

10 interrupted or otherwise adversely affected by a prbblem 
such as a priority or timing conflict, a broadcast or 
wireline signal interference, among other conditions. 
Calls involved in a call flow exception are processed in 
ways that result in a minimal rejection rate in 

is accordance with the present invention « While the 
rejection rate is minimized, some calls can be rejected 
due to physical constraints and limitations associated 
with some interfaces on the PSTN side, such as loop start 
trunks- Loop start trunks provide a single point o£ 

20 contact for each subscriber in the NIU 28 which is 
helpful when resolving some call flow exceptions. As 
will be described below, the AN-LE interface protocol of 
the present invention allows for processing exceptions in 
digital and analog modes differently. 

25 Call flow exception or glare conditions occur due to 

the multiple points of control along the path of the 
call. As stated previously, the AN-LE interface protocol 
of the present invention operates in a system wherein the 
RBU 26 and CPE 32 are programmed to handle a number of 
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call processing issues, as opposed to requiring the NIU 
28 to handle all of the call processing, as does the LE 
in a V5 or ^ other existing protocol -based system. For 
example, a subscriber can go off -hook on a telephone 32 
5 (blocks 426, 422, 430 and 432) to make an outgoing call 
while an incoming call is being processed simultaneously 
in the PSTN for that particular subscriber (blocks 422 
and 424) . The processing of the incoming call, as 
illustrated in (blocks 426, 428, 430, 432, 434, 436, 438, 
10 440, 442, 444, 446, 447, 448 and 45Q in Fig. 7, is 
substantially the same as that described above in 
connection with Pig. 7. Thus, a glare condition appears 
somewhere along the path that cannot be avoided. The 
protocol of the present invention provides resolution to 
15 this glare condition between the CPE and the RBU in favor 
of the incoming call. The RBU 26 therefore sends a ring- 
trip signal (block 452) to the NIU 28 (block 454) upon 
reception of an off -hook signal from the CPE 32. As 
stated previously, the protocol of the present invention 
20 differs from existing protocols in that the of f -hook 
signaling was not transmitted to the NIU 28. Instead, 
the CPE 32 processed the event to determine that an off- 
hook condition was present and the RBU, in turn, 
processed the off -hook condition to determine that a 
25 ring-trip signal was necessary at the NIU 28. 

A glare condition can also occur between the RBU and 
the NIU, that is, the RBU transmits a CMD_OTG_CALL SETUP 
command at the same time the NIU transmits a 
CMD_INC_CALL_SETUP command, as shown In Fig. 18. The 
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outgoing call processing illustrated in blocks 4 56, 458, 
462, 466, 468, 470, 472 and 476 US substantially 
equivalent to that described above in connection with 
Fig. 6. Meanwhile, the incoming call processing, 
5 illustrated in (blocks 459, 461, 463, 465, 467, 469 and 
471 is siibstantially equivalent to that described above 
in connection with Pig. 7. The RBU, however, preferably 
rejects the incoming call (block 469) and proceeds to 
process the outgoing call in accordemce with the present 

10 inventicm. The MIU, on the other hand, processes the 
outgoing call differently, depending on whether it is ah 
analog or digital system. In an analog system, the 
outgoing call is connected to the incoming call (block 
470) . That is, the sxibscriber is connected to a calling 

15 party instead of receiving a dial tone. The NIU 28 
processes the outgoing call as an incoming call by 
transmitting change call type and change call priority 
commands (blocks 480, 482 and 484) to the RBU 26, as 
described above in connection with Figs. 12 and 13. In a 

20 digital system, the outgoing call is processed by the NIU 
28 on one of the available channels, euid the NIU 28 
rejects the incoming call from the PSTN. The present 
call is therefore treated as an outgoing call in the 
manner described above in connection with Pig. 6. 

25 With reference to Pig. 19, a glare condition can 

occur between the NIU 28 and the PSTN, that is, when the 
NIU 28 is about to process an outgoing call (blocks 488, 
490, 492, 494 and 496), but it receives cm incoming call 
request from the PSTN (block 498). Call processing of 
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the outgoing call illustrated by blocks 488, 490, 4^2:^ 
494 and 496 is described with reference to Pig. 6. This 
glare conditdon, in which the outgoing call is favored, 
is also treated differently, depending on whether an 
5 analog or digital system is in use. The signals for 
ringing the NIU and seizing the trunk are lost (blocks 
500 and 502). In an cuialog system, the outgoing call ist 
connected to the incoming call. The subscriber i^ 
therefore connected to a calling party instead of a dial 
10 tone. Accordingly, the NIU 28 processes the call as an^ 
outgoing call (block 504) and, upon termination of a 
priority assigning timer (block 506) , the NIU 28 provides 
the default call priority of a call to the RBU (blocks 
508 and 512). In a digital system, the outgoing call is 
L5 processed on one of the El channels ports on the NIU 28 . 
The NIU 28 therefore rejects the incoming call from the; 
PSTN. In an analog system, the NIU 28 leaves the loop 
start trunk imeuiswered. The PSTN equipment is thereby 
given an Indication that the designation CPE 32 is not 
!0 answering the call when, in fact, the CPE 32 never 
actually received a call. In a digital system, the NIU 
28 rejects the call using a congestion signal transmitted 
back to the PSTN. 

Most call flow exceptions are handled by the RBU 26 
5 or CPE 32. One exception, however, occurs when a 
siabscriber does not hang up at the end of a call (block 
514) . As shown in Pig. 20, the CPE 32 plays a call 
reject tone and sets a Call_Reject_Tone timer or Set_Off- 
Hook timer (blocks 516 and 518) . If the CPE 32 detects 
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an on-hook condition (block 520) . it enters an idle state 
(block 522); otherwise, the CPE 32 increases the volume 
of the tone jupon time-out (blocks 524 and 56. The CPE 32 
also sets an Of f -Hook_Waming timer (block 528) . If the 
CPE 32 goes on-hook, then it continues in an idle state 
(blocks 530 and 532); otherwise, the CPE 32 ceases to 
play the call reject tone when the warning timer times 
out and sets a Silence timer (blocks 534, 536 and 538) . 
If the CPE 32 does not go on-hook (block 540) and the 
Silence timer times out, the CPE 32 continues to play the 
call reject tone for the subscriber (block 540) . 
Meanwhile, the AN-LE link has already been destroyed for 
that call if one had been set up by the RBU. 

Commands sent between the NIU 28 and RBU 26. as 
15 described above in connection with Figs. 6-20,. preferably 
require responses within a predefined period of time. 
Although a reliable communication link is implemented 
between the NIU 28 and RBU, both devices are able to 
process worst-case scenarios when a message is lost or 
delayed in accordance with the present invention. Each 
message requiring a response causes the NIU 28 or RBU 26 
to set a -timer during which a reply should be received. 
If the reply is not received during that period of time, 
the RBU 26 or NIU 28 undertake exception handling 
measures. These measures vary depending on the message 
being sent. For exaii?>le, if a OTG_CALL_SETUP command is 
sent and its corresponding timer expires, the RBU 26 
sends a DROP_CALL command to the NIU 28 and a command to 
reject the call to the CPE 32. If the AN-LE link 30 has 
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gone down, the RBU 26 reassigns the call to a new link;:! 
along with other calls. When the time out occurs! 
DROP_CALL ccpnand is sent on the new link. Eacpiratioii o^? 
a timer following the command INC_C»LL_SETDP causes the 
5 NIU 28 to send a release call identification (ID) signal 
to the RBU. At this time, the NIU 28 cannot reference 
the incoming call by a link identification number or Ja i 
time slot number and, therefore, requires use of the Call ^ 
ID . The RBU 26 queries the CPE 32 to request that the 
10 CPE 32 stop ringing. If a DROP^CALL command is sent, tlie : 
link carrying the call is used repeatedly by the RBU 26 
until the timer expires, at which time the RBU 26 tries 
sending the DROP_CALL commemd on a new link. If a link 
has gone down, the RBU 26 reassigns the call to a new 
15 link, along with other calls. If a link carrying a call 
related to the command STATUS_QUERY is still operational, 
the RBU 26 attempts to send the STATUS__QDERy command 
repeatedly until the timer expires. The command is then 
transmitted on a new link. If the link was down, the RBU 
20 26 reassigns the call to the new link, along with other 
calls. The RBU 26 attempts to transmit the command to 
reassign a channel link a number of times if the link 
carrying the call related to this command is apparently 
still operational. When the timer expires, the RBU 26 
25 transmits a DROP_CALL command indicating a lost packet to 
the NIU 28. The RBU 26 tries the command on a new link 
and informs the CPE 32 to release the air channel. 

In accordance with the present invention, a 
Ring_Trip timer for incoming calls is implemented in both 
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the RBU 26 and the NIU 28- The timer is most frequently 
used in the NIU 28 and is preferably the only timer that 
system operators can change. The RBU 26 and CPE 32 each 
have a RBU/ CPE timer. The RBU/ CPE 32 timer stops a 
S ringing CPE 32 in cases where the STOP_RING command from 
the RBU 26 to the CPE 32, or from the NIU 28 to the RBU, 
is lost. To reduce the processing required to chamge the 
same parameter into different processors, the NIU 28 is 
programmed to be a master controller under these 

10 circumstances. Thus, if the RBU 26 of CPE 32 timer 
expires, the RBU 26 queries the status of the CPE 32 from 
the NIU 28. If the NIU 28 indicates that the CPE 32 is 
still ringing, the RBU 26 or the CPE 32 resets the 
RBU/CPE 32 timer; otherwise, the RBU 26 stops sending 

15 ring signals to the CPE 32 and aborts the c«ai.- 

With reference to the illustrated example in Fig. 3, 
the link layer 60 can be implemented using a time slot or 
channel on each of the four Els of the AN-LE links 30 and 
constitute a control channel for that El. Alternatively, 

20 the link layer can consist of a number control c h a nn els 
that are multiplexed as a separate link connected to a 
serial port on the AN and LE terminals. 

As will be described below, loss of one of the Els 
does not result in the loss of the control channel. In 

25 contrast with the V5 protocols, the other three Els can be 
used for common channel signaling without requiring 
reinitialization or switchover protocol to invoke a 
backup-control channel or another nonf ailed link. The 
VS. 2 protocol permits the in5)lementation of as many as 16 
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Els and one, two or three control chazmels on respective 
AN-LE links 30. If two or three control channels are 
used, one oi the cheumels is designated as the primary 
control c hanne l . If the El corresponding to the primary 

5 control channel is lost, then a number of administrative 
operations and handshaking routines must be invoked to 
switch control to another link and to commence control 
signaling on the auxiliary control channel. The V5.2: 
protocol therefore is disadvantageous becaiise it requires 

0 additional software and administrative functions . The VS . l 
protocol permits only a single El with one or more control 
chauinels and therefore does not have any provisions for 
back-up control channels or transfer of calls upon link 
failure. Thus, the protocol of the present invention is 

5 advantageous because it allows for maintenance - of control 
chcuinels and calls following link failure with minimal 
processing. 

Initialization and operation of the link layer 60 of 
the protocol of the present invention will now be 

) described with reference to Figs. 21-26 and Pigs. 27-30, 
respectively. The flowcharts in Figs. 21-24 apply to both 
end points of the AN-LE link; however, they are drawn for 
only one end point for illustrative purposes. The 
description of Figs. 21-24 will be with reference to the 

> RBU end point by way of an example, with the imderstanding 
that the description also applies to the NIU. Following 
initialization of each physical AN-LE link 30, the link 
end points (e.g., the RBU 26 and the NIU 28) each begin to 
send Crad_StartInit requests to commence initialization 
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(blocks 550 and 552) to the other end point once every 
second. A TSc_Signatiire Counter is incremented upon 
transmission^ of each Cnid_StartInit request (block 554), as 
shown in Pig. 21. Transmission of Cmd_StartInit requests 
5 by the link end points 26 and 28 continues indefinitely 
until an initialization request acknowledge (e.g., 
Rsp__StartInit) is received. The end points 26 and 28 each 
enter a second initialization state. 

As illustrated in blocks 556, 558, 560 and 562 of 
10 Fig. 22, the TX_Signature Counter is incremented when the 
StartInit_Tx timer maintained at each end point 26 and 28 
expires before receipt of an Rsp_StartInit response 
message. Another Cmd_StartInit message is therefore 
retransmitted and the StartlnitJTX timer is reset to a 
15 predetermined time, such as one second. The StartInit_Tx 
timer continues to decrement until it either overflows 
again, or a Rsp_StartInit message has been received. 

AS shown in blocks 564, 566, 568 and 570 of Pig. 22, 
upon receipt of a Rsp_StartInit from the NIU. the RBU is 
20 programmed to determine whether the Signature transmitted 
therewith matches that of the last Signature received. If 
it does not, then the RBU continues to send Cmd_StartInit 
commands to the NIU. If the Signature does match, then 
the Startlnit_»c timer is reset, and a flag 
25 Rx:_Rsp_StartInit is set. The RBU then determines whether 
the Tx_Rsp_StartInit flag was set by the NIU, as will be 
described below with reference to block 576 . If it has 
not, then the RBU continues to wait for an Rsp_StartInit 
. from the NIU; otherwise, the device enters the next 
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initialization state described in connection with Fig. 23: 
for the NIU and Fig. 24 for the RBU. 

While transmitting Cnui_StartInit commands to the NIU 
or RBU, respectively, each end point RBU or NIU also 
5 receives Cand_StartInit commemds from the other end point 
which contain a Signature (block 572) . For example, the 
NIU both respond with a Rsp_StartInit and with the 
Signature (blodc 574). If the Signatures of the iMt 
commands from the RBU match, the NIU sets a 
10 T5c_Rsp_StartInit flaig (block 576) . If the Rsp_StartInit 
flag is set (block 568) , then the RBU continues to the' 
next initialization state; otherwise, it continues to 
exchange Cmd_StartInit requests with the NIU and awaits 
initialization recpiest acknowledgment (i.e., a 

15 Rsp_StartIxiit message) . 

The NIU is programmed to receive a link 
identification number, an RBU identification number and an 
RBU address from the MCU 34, as shown in block 580 in Fig. 
23. After setting internal data (block 582), the NIU 
20 transmits a Cmd_Conf igureLink connnand to the RBU (block 
584) comprising the link identification number, the RBU ID 
and the RBU address. The NIU subsequently enters the 
Multi-Frame Operation_Of f state described below in 
connection with Fig. 25. 
25 When the initialization request acknowledgment 

exchange is complete, the RBU awaits the receipt of a 
Crad__Conf igureLink, as shown in block 586 in Pig. 24. This 
command is preferably only sent from the NIU to the RBU 
after completion of the Cmd_StartInit and Rsp_StartInit 
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exchange. The NIU assigns a two bite identification 
number to this particular El, and the RBU proceeds to 
store that identification numbers, along with infonnation 
about the RBU itself (e.g., an RBU identification number 
and address). If the link ID, the RBU ID and the RBU 
address have not already been set (block 588) , the RBU 
sets a RESPONSE variable to a value corresponding to a NEW 
condition (block 590). If the link ID, RBU ID and RBU 
address have already been set. and the link ID is the same 
value as the previously set link ID (block 592), the RBU 
sets the RESPONSE variable to a value corresponding to 
REPEAT (block 594) . If the link ID is different, then the 
RBU sets the RESPCMISE variable to a value indicating ERROR 
(block 596) . The RBU subsequently transmits an 

15 Rsp^ConfigureLink, along with the RESPONSE variable to the 
NIU (block 590), before entering the Multi-Frame 
Operation_Off state described below. 

With reference to Pig. 25, the NIU awaits receipt of 
an event from the MCU 34 to begin operation (block 600) . 
20 The NIU subsequently determines when it is prepared td 
commence a signaling protocol for the transmission of 
sequenced messages " along an AN-LE 30 link. The NIU 
transmits the Cmd^BeginSeqProtocol command to the RBU 
(block 602) to indicate that the NIU is prepared to 
25 commence multiple frame operation. Sequenced messages are 
preferably not transmitted between the link end points 
(i.e., the RBU and NIU) until the sequencing protocol is 
set up as described below. The NIU sets a Begin_MFO_Rfitry 
timer and a counter having the same name to the value of 
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one (block 604} . The NIU is prograunmed to await the 
receipt of a R8p_SegProtocol conunand from the, other end 
point (i.e.; the RBU) which indicates the sequencing 
protocol statue -Begin" (block 606). if a Rep_Sequence 
Protocol Begin is received from the RBU (block 608) , then 
the NIU commences sequence numbering and assumes that the 
RBU is available. The NIU is therefore prepared for 
multiple frame operation and commences operation in 
accordance with the flow chart depicted in Pig. 29. If a 
response is not received before the Begin_MPO_Retry timer 
times out, then the timer is reset and the NIU continues 
to operate in the MPO__Off state (block 610) . 

With reference to block 612 in Pig. 25, receipt of a 
Cmd_Term_SeqProtocol command at an end point operating in 
15 the MFO_pff state from the other end point indicates a 
misalignment. In accordance with the present invention, 
the receiving end point can transmit a Rsp_SeqProtocol 
command with status information indicating that sequence 
messaging has been terminated to induce the other end 
20 point into the MFO_Off state (block 614) . Similarly, 
receipt of a Cmd_SeqStatusUpdate command while in the 
MFO_Off state also indicates misalignment (block 616) . 
Accordingly, the receiving end point transmits a command 
to terminate sequencing pirotocol (block 618) . The 
25 messages in blocks 614 and 618 can be sent by either the 
NIU or the RBU to update flow control of the other end 
point. The Crad_TermSeqProtocol command passes the 

sequence numbers of the messages which were most recently 
sent and received. 
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If a Cnid_StartInit is received from the RBU (block 
620) , the NIU is prograraraed to transmit warnings to the 
RBU (block 6^2) to clear related data and to set the MPO 
variable to the OFF state (block 624). The NIU 

5 siibseqaently undergoes initialization as described above 
in connection with Figs. 21-24. If no Rsp_Seq_Protocol 
command is successfully sent to the Nin before the 
expiration of the BeginJMFO_Timer (block 626) , and the 
Begin_MFO_Retry counter is greater than a predetermined 

10 maximum number of retries (block 628) , the NIU sends 
warnings signals to the RBU (block 630) and commences link 
initialization as described in Figs. 21-24. If the 
maximum number of retries have not been reached, then the 
NIU sets the Begin_MFO_Retry timer, increments the 

15 Begin_MFO_Retry counter (block 632) and continues to 
operate in the MFO_Off state. 

Multiple frame operation in the OFF state for the RBU 
will now be described with reference to Fig. 26. The RBU 
awaits receipt of the Cmd_BeginSeqProtocol coramcuid from 

20 the NIU (block 634) . Once this command is received, the 
RBU transmits an Rsp^SeqProtocol command indicating the 
beginning of multiple * frame operation (MFO) and the 
transmission of sequenced messages between the link end 
points (blocks 636 and 638) . A number of vsuriables are 

25 initialized and a timer (Tt) is set to three (3) seconds 
(block 640) . If RBU is not prepared for MPO, the RBU 
responds with a Rsp_SeqProtocol begin fail condition 
(block 642) . The RBU similarly receives and responds to a 
Cmd_TermSeqProtocol command (blocks 644 and 646) , a 
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Cmd^SegStatusUpdate command (blocks 648 and 650) , auid 
Cknd_StartInit command (blocks 652, 654 and 656) , as 
described above in connection with the NIU. 

With reference to Fig. 27, a Qnd_LinkFail command can 
5 be sent fay either the RBU or the NIU across a xion* failed ; 

El upon detection of a failed El. When the RBU receives H^iP 
this message, it is programmed to move calls on the failed ||uJ: 
link to ouiother link. The end point (i.e., either this RBU 
or the NIU) receiving the link fail command reports 

10 warnings to an element management system (EMS) and an 
administrative terminal (block 658). Link hardware (i.e., 
the El interfaces 56a and 56b) on each trunk board 38a and 
38b is reset and initialized if necessary (block 660), 
among other maintenance operations. If the link is Iflf 

15 recoverable (block 662) , a Cmd^inkRecover commamd is sent 1; 
to the other end point over the link that is being 
recovered (block 664) auid a Link_Recover timer is set 'ifM 
(block 666) . |: 
With reference to Pig. 28, both end points are fk 

20 programmed to await receipt of a Cmd_StartInit command or ; y/l 
for the e3q>iration of the Link_Recover timer (blocks 672 
and 674) . If either condition exists, the link undergoes 
initialization. If the timer does not expire, the end 
point is progrcumned to send a Cmd_Link_Recover command 

25 (block 676) to the other end point, as well as reset the 
Iiink_Recover timer and increment the Link_Recover counter 
(block 678) . If a Cmd^Link^Recover command is received 
from the other end point (block 680) , the receiving end 
point is programmed to send an Rsp^Link^Recover if the end 



'wo 98/09448 



37 - 



PCT/US97/1S25S 



10 



point can also resume service (block 681) . The 
Cind_Recover_Rx bit is also set (block 682} . Similarly, if 
the end point receives a Rsp_LinkJRecover acknowledgment 
(block 680) to its transmission of a Cmd_ljink__Recover 
command (block 676), the end point sets the Rsp_Recover_Rx 
bit and clears the Iiink_Recover timer (block 688) . If 
both the Cmd__Recover_Rx bit and the Rsp_Recover_Rx bit are 
set (block 690). then the end points enter the MPO_Off 
state. Upon recovery of the link and before entering the 
MFO__Off state, the Rsp_Recover_Rx bit and the 
Cmd_Recover_Rx bit are preferably cleared. Another state 
can be provided to test the link via a loop back or a bit 
error rate test (BERT) . Once the MFO_Of f state is entered 
by both end points, the MFQ__On operations can begin. 
15 If the sequencing protocol has begun between the two 

end points, that is, the RBD and NIU are operating in the 
MFO_On state, and the OnBd_TermSeqProtocol is received from 
one of the end points (block 692), then an Rsp_SeqProtocol 
command is transmitted back to the end point (block 694) 
20 to indicate that termination is successful and that the 
end points are now operating in the MPO__Of f state (block 
696) . In addition, the FBU and not the NIU can receive a 
Cmd__BeginSeqProtocol command (block 698) from the NIU, and 
respond with an Rsp_SeqProtocol response signal with 
25 status information indicating that commencement of the 
sequencing protocol failed (block 700) since it is in the 

MFO__On state already. 

With continued reference to Fig. 29, either end point 
can receive a Cmd__FrameReject signal from the other end 
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point: (block 702) . Thie commzmd can have two meanixigs; 
depending on the data within the message. Either end 
point (e.g. the RBU) can send this conunand upon detection 
of invalid or missing frames. The message tells the NIU, 
5 for example, to terminate the current transmission and to 
commence retransmission at the specified sequence number, 
as illustrated below in Pigs. 30-38. A Rsp_Prame_,Reject 
response to the Prame_Reject command is transmitted by the 
NIU to indicate that it received the reject cbmmahd and is 
10 commencing retransmission (block 704) . An Rx_Reject 
counter is incremented by the NIU (block 706) . if the 
number of rejected frames exceeds a predetermined 
threshold, the link is considered to have failed The NIU 
is programmed to report the error to the maintenance 
15 equipment. The NIU is programmed to continue transmission 
at the specified sequence number in the MFO_On state 
(block 708) . If, on the other hand, an Rsp_FraraeReject is 
received (block 710), the reject bit is cleared (block 
712) and operation continues in the MPO_On state. The 
20 reject bit is analyzed (block 716) by the NIU when a 
sequence packet is received (block 714) . if the reject 
bit is on, . the packet is thrown away (block 718); 
otherwise, the next expected sequence number is compared 
with that of the received packet (block 720). If no match 
25 is found, a Cmd_PrameReject command is sent to the other 
end point (block 722) . Further, the reject bit is set, 
and Tx_Reject covmter is incremented (block 724) . if the 
next escpected sequence number matches that of the received 
packet, the NIU, for exaraple, is programmed to determine 
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whether its receive window or buffer is 80% fxill (block 
726) , or a time -transmit (Tt) timer has esqoired and, if 
so, to transmit a Cmd_SetStatusUpdate command (block 728) . 
This command passes the sequence nxunber of the messages 
most recently sent and accepted and updates the window 
(block 730). If the received window is not 80% full, or a 
Cmd SeqStatusUpdate commamd has been sent, then the packet 
is processed in accordance with the call processing 
control (block 732) . 

With continued reference to Pig. 29, if ah end point 
receives a Cmd_Iiink_Pail command on another non-failed El 
link (block 734), the end point sends warnings to the EMS 
and moves calls to an operating link (block 736) before 
entering the MFO_Off state (block 738) . The end point 
15 subsequently executes the link fail routine (Pig. 27) for 
the failed link. The end point operates similarly if a 
Cmd_StartInit command is received (blocks 740, 742 and 
744) , except that it executes a link initialization 
routine (Figs. 21-24) . If a Cmd__SeqStatuBl^date command 
20 is received (block 746) , the receiving end point updates 
receive window (block 748) and increments an Rx_Update 
counter (block 750) . If a request for a return update by 
the other end point is desired (block 752) , a 
Cmd_SeqStatusTJpdate commsuid is sent (block 754) . If a 
25 non-sequence packet is received (block 756) , the receiving 
end point transmits a Crad_Error command to the sending end 

point (block 758). 

With continued reference to Fig. 29, if the Tt timer 
is e:q>ired (block 760) , a Cmd_SeqStatusUpdate command is 
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sent to the sending end point (block 762) . if the 
Tx_Reject counter or the Rx_Reject counter is greater than 
a maximum pir^determined number of allowable rejects (biock! 
764), both reject counters are cleared and a report is 
5 made to the EMS (block 766). If the Rx_I^date coxmter is 
zero (block 768), the end point determines if the 
Di)date_Fail bit is set (block 770). If so, then: a ; 
Cmd_liinJcFail command is transmitted on another link (block 
772). If the l3|xJate_Pail bit is not set, then the exid 4 

0 point sets the bit (block 774), as well as the Tt timer 
(block 776) . If the Rx_Update cotmter is not zero, then 
the cotinter is cleared, and the Dpdate_Fail bit is also 
cleared (block 778), before setting the Tt timer. If a 
Cmd_LinkPail command is sent, then the end point provides ^ 

5 warnings to the EMS, clears received window data and sets 
the iqpdate_Fail bit before commencing movement of calls to 
another link (block 780) . The MFO bit is then set to OFF 
(block 782) , and the end point undergoes the link fail 
routine described above in connection with Pig. 27. 

1 Flow control in the link layer 60 is illustrated in 
Pigs. 30-35. Figs. 30-35 also illustrate queuing and 
processing delays that are normal operations of the 
protocol of the present invention. The niimbers in the 
boxes represent sequence numbers for packets. The 
transmit side and the receive side can be either the RBU 
or the NIU since flow control is essentially the same for 
both, except for differences mentioned below. The 
diagrams in Figs. 30-35 represent commianication in one 
direction only for illustrative purposes. Bi-directional 
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communication can occur such that the procesBes depicted 
in these figures are occ\xrring in tw directions 
simultaneousiy. Further, each diagram in the respective 
figures represents a particular condition, but 
5 combinations of these conditions can occur. Sequence 
numbers preferably range from 0x00 to 0x7F hexidecimal. 
The high bit is reserved for nonsequenced commands. A 
packet with the high bit set in the sequence number is 
processed as a nonsequence packet. For illustrative 
10 purposes, the window length is 10 and the maximum number 
of frame rejects is 3. These variables and the timer- 
transmit timer described below are adjustable for optimal 
perf oimance . 

With continued reference to Figs. 30-3S, each side of 
15 an AN-LE link 30 sends a timed update every 3 seconds 
containing the last transmitted sequence nuinber and the 
last received sequence number. The timer is called a 
timer- transmit or Tt timer. The transmit and receive 
sides preferably guarantee an update at least every 3 
20 seconds. If the other end of the AN-LE link 30 does not 
receive an update upon two eacpirations of its own Tt 
timer, then the link may" have failed. The AN or LE (e.g., 
RBU or NIU) subsequently sends a Cmd__Link_Pail command to 
the other side and stops multiple frame operation on that 
25 particular link. The RBU, in accordance with the present 
invention, begins to move calls to the other links. Since 
the RBU is responsible for channel assignment on the AN-LE 
link, an alarm is sent to the element manager system and 
to the administrative terminals by the transmit and 
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receive sides of the link. The Tt timer also helps to 
identify a lost packet in low traffic situations. If a 
packet is lo6t during low traffic conditions, the Tt timer 
causes an update by that particular transmit or receive 
5 side to be sent to the other end point terminal to 
identify the missing packet . During low traffic and 
normal operating conditions, the transmit side sends a 
packet having sequence number 1 which is received at the 
receive side. The Tt timer is set to 3 seconds at the 
10 beginning of the operation. Dt>dates are sent and the 
timer is reset vdienever it expires . Updates aire 
preferably not sent until the receive window is 
approximately 80% full (i.e., 8 packets have been received 
in a window having a 10 packet length) . m the 
15 illustrated example (i.e.. Pig. 30). only 5 packets are 
sent by the transmit side before the Tt timer expires. 
The transmit side therefore sends a Cmd__Seq_Status_Update 
(CSSU) command (block 786) to the receive side and updates 
the Tt timer. The transmit side has no further packets to 
20 send. After the Tt timer of the receive side expires, 
the receive side transmits a CSSD commamd (block 788) to 
the transmit side. Thus, there are no xmacknowledged 
transmitted packets at this point. The transmit side 
sends a packet having sequence number 6 such that there is 
25 now one xinacknowledged packet received by the receive 
side. When the Tt timer expires, the transmit side sends 
a CSSU command (block 790) . The receive side also sends 
an update or CSSU command (block 792) upon expiration of 
its Tt timer. 
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Pig. 31 illustrates heavy traffic but normal 
operating conditione. The packets transmitted in Pig. 31 
occur withirt a time frame that is less than 3 seconds, 
such that eacpiration of the Tt timer on either the 
transmit or receive sides is not shown for illustrative 
purposes. The transmit side sends packets with sequence 
numbers 1-8 to the receive side. When 8 packets are in 
the receive window, the receive side sends an update or 
CSSU command 794 to the transmit side. Meanwhile, the 
transmit side has sent packets having sequence numbers 9 
and 10 before hitting the end of its transmit window and 
refraining from further transmission. The CSSU command 
794 from the receive side is received at the transmit 
side; however, only 8 packets are acknowledged while 2 
15 packets remain unacknowledgfed. The transmit side 

continues to transmit packets having sequence numbers Il- 
ls . When another 80% of the receive window has occurred, 
the receive side transmits another CSSU command 796 to the 
transmit side leaving 2 packets (i.e.. packets 17 and 18) 

20 iinacknowledged. 

Pig. 32 illustrates link layer processing when there 
is an error condition. For-exan«)le , the packet having 
sequence number 2 was not received by the receive side. 
The receive side detects that there is a missing packet 

25 and sends a Frame_Reject command 798 to the transmit side . 
The sequence packets are ignored until a Prame^Reject 
response 800 is received from the transmit side. The 
receive side transmits the missing sequence number and 
commences incrementing a Reject^Tx counter. The transmit 



wo 98/09448 



f P CT/USS(7>15259 

- 44 - 



.10 



side receives the Prame_Reject command and ceases to 
transmit additional packets. The transmit sides alsb 
generates a ^ame_Reject response signal 800 and commences 
sending packets from the specified sequence nuiriber 
transmitted along with the Prame_Reject command. 
Meanwhile, the receive side ignores the packet hayixig 
sequence numbers 3 and 4, but begins accepting sequence 
packets 2, 3 and 4 upon receipt of the Prame_Reject 
response 800. As with Pig. 31, timed updates using the Tt 
timer are not represented in this error condition diagram 
or in Figs. 32-35 below for illustrative purposes. 

Fig. 33 illustrates flow control when multiple errors 
have occurred. For example, a packet having sequence 
number 23 can contain an error condition. The receive 
side detects a missing packet and sends a Frame_Reject 
command 802 to the transmit side containing the missing 
sequence number. The receive side also commences 
incrementing a Tx_Reject counter. The transmit side has 
already transmitted packets having sequence numbers 24 suid 
25 before it receives the Prame_Reject command 802. These 
and other packets are ignored at the receive side until a 
Prame__Reject response 804 is received. The transmit side 
commences retransmission of packets beginning with the 
sequence number provided to the transmit side by the 
25 Prame_Reject command 802. The packet having sequence 
number 24, however, also has an error condition during 
retransmission. Accordingly, the receive side transmits a 
Prarae_Reject command 806 indicating the sequence number 24 



15 



20 
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of the missing packet and increments the Tx_Reject counter 
again. 

The transmit side has already sent packets 25 and 26 
before it receives the Frame__Reject command 806. The 
5 transmit side sends the Fraine_Reject response 808 and 
begins to retransmit packets beginning with sequence 
number 24. Once again, a missing packet is detected and 
the receive side sends a Prame_Reject command 810 to the 
transmit side indicating the sequence number. The receive 

10 side also increments the TX_Reject counter to 3. The 
transmit side ceases to transmit packets and responds with 
a Prame_Reject response before retransmitting packets 
commencing with the sequence number 24. If the counter 
exceeds a predetermined maximum number of Frame_Rejects 

15 before the expiration of the Tt timer, the link will be 
declared to have failed and a Link_Fail routine is 
executed as described in connection with Fig. 27. 

Pig. 34 illustrates when there is an idle traffic 
communication and the loss of communication in one 

20 direction. The Tt timer is set to 3 seconds, but 
communication is lost from the transmit side to the 
receive side. Since the Tt timer on the receive side 
expired, the receive side sends an CSSU command 814 to the 
transmit side and resets its Tt timer. The transmit side 

25 Tt timer also e3q>ires. The transmit side sends a CSSU 
command 816 to the receive side which has an error 
condition. The receive side once again resets its Tt 
timer after it expires and sends a CSSU command 818 to the 
transmit side. The transmit side sends another CSSU 
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command 820* Upon detection o£ no update during the last 
two cycles of the Tt timer, the receive side sends a 
Qiid_Link_Fail command 822 to the trauismit side. The 
receive side terminates multiple frame operation on thii^' 
5 link and sends a warning to the EMS or maintenance 
terminal. The RBU, in accordance with the present 
invention, commences moving calls to another link at this 
time 824. At the transmit side, the Link_Failure command 
is received 826 and multiple frame operation is terminated 
10 at this end point of the link. 

Pig. 35 illustrates link recovery. A warning has 
been sent to the EMS 828 when a Link_Failure condition is 
detected. As stated previously, the RBU commences moving 
calls to another link. Both the transmit and the receive 
15 sides set Link_Recover timers 830 and 832. If the problem 
is fixed, one of the sides can send a Cmd_Link_Recoyer 
command 384 to the other side. When the other side is 
ready, it also sends a Qnd_Link_Recover sigzial 836 to the 
other end point. The side that transmitted the 

20 Cmd_Iiink_Recover signal sets a Cmd_Recover_Rx bit 838 upon 
receipt of the Cmd_Link_Recover from the receiving end 
point. Both sides then proceed to generate 

Rsp_Link_Recover signals 840 and 842, respectively, and 
enter a multiple frame operation state 844 and 846. 
25 While certain advantageous embodiments have been 

chosen to illustrate the invention, it will be understood 
by those skilled in the art that various changes and 
modifications can be made herein without departing from 
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the scope of the invention as defined in the appended 
claims . 
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What Is Claimed le 

1. A method of processing calls transmitted between a 
subscriber unit, an access network device connected to the 
subscriber unit, and a network interface device connected 
5 to the access network device via at least one 
communications link comprising a number of channels and to 
a network, comprising the steps of: 

determining via said access network device whether 
one of said channels is available on said communications 
10 link for an outgoing call initiated by said subscriber 
unit; 

assigning said channel to said outgoing call using 
said access network device; 

notifying said subscriber unit that said channel is 
15 available; and 

notifying said a network interface device that said 
outgoing call is forthcoming and of said channel on which 
said outgoing call is being treuismitted, said network 
interface device being programmable to process said 
20 outgoing call using said channel assigned by said access 
network device without first assigning one of said 
channels and notifying said access network device of said 
channel selected by said network interface device. 



25 2. A call processing method as claimed in claim 1, 
further comprising the step of reporting an off -hook 
condition at said subscriber unit to said access network 
device as an indication of said outgoing call in lieu of 
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sending a physical off -hook signal generated by said 
' subscriber unit. 

3. A call processing method as claimed in claim 1, 
5 further comprising the steps of: 

determining whether said network interface device can 

accept said outgoing call; 

transmitting a response signal from said network 
interface device to said access network device indicating 
10 when said outgoing call is not successfully received by 
said network interface device; and 
releasing said channel. 

4. A call processing method as claimed in claim 3, 
15 further con5>rieing the step of transmitting a signal from 

said access network device to said subscriber unit to 
indicate that said outgoing call has been rejected. 

5. A call processing method as claimed in claim 1, 
20 further comprising the steps of: 

determining whether said network interface device can 
accept said outgoing call; and 

seizing a trunk using said network interface device 
if said network interface device accepts said outgoing 
25 call. 



6. A call processing method as claimed in claim 5, 
further comprising the steps of: 
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detextnining priority of said outgoing call at said 
network interface device using dialed digits received from 
said subscri£>er unit; and 

notifying said access network device to process said 
5 outgoing call in accordance with a different priority. 

1. A method of processing calls transmitted between a 
subscriber unit, an access network device connected to the 
siibscriber unit, and a hetviork interface device connected 
10 to the access network device via at least one 
communications link comprising a number of channels and to 
a network, conprising the steps of : 

receiving a ring signal at said network interface 
device from said network, said ring signal corresponding 
15. to ein incoming call; 

trcuismitting a command signal from said network 
interface device to said access network device indicating 
that said incoming call is forthcoming; 

determining via said access network device whether 
20 one of said chauinels is available; 

assigning said channel to said incoming call using 
said access network device; 

notifying said subscriber unit if said channel is 
avai lable ; and 

25 transmitting a ring- trip command to said network 

interface device from said access network device. 

8. A method of processing calls transmitted between a 
subscriber unit, an access network device connected to the 
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subscriber unit, and a network interface device connected 
to the access network device via at least one 
communication link comprising a number of channels and to 
a network, comprising the steps of: 
5 determining via said access network device whether 

one of said channels is available for a call; 

detecting a condition to terminate said call at said 

access network device; 

determining whether said network interface device 
10 should be notified of said condition; and 

transmitting a command to terminate said call to said 
network interface device if said network interface device 
had been notified that one of said channels on said link 
had been assigned for said call by said access network 
15 device . 

9. A method of processing calls transmitted between a 
subscriber unit, an access network device connected to the 
subscriber unit, and a network interface device connected 

20 to the access network device via at least a first 
communications link and a second communications link, each 
coiT?>rising a number of channels, and to a network, 
conqorising the steps of: 

detecting failure of said first communications link 

25 by at least one of said access network device and said 
network interface device, said first communications link 
con5>rising a first channel for transporting a call; 
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locating a second channel on said second 
communications link that is available to transport said 
call using said access network device; and 

trouismitting a command to said network interface 
5 device from said access network device to estcQDlish said 
call on said second channel, said command comprising data 
selected from the group consisting of an identification 
number corresponding to said second channel, an 
identification number corresponding to said first channel, 
10 and an identification number for said first communications 
link. 

10. A method as claimed in claim 9« further comprising 
the steps of: 

15 transmitting a response signal notifying said access 

network device if said network interface device is unable 
to transfer said call to said second chsmnel; and 

notifying said subscriber unit to terminate a call 
connection established between said subscriber unit and 

20 said access network device to transport said call upon 
receipt of said response signal. 

11. A method of processing calls transmitted between a 
subscriber unit, an access network device connected to the 

25 subscriber unit, cuid a network interface device connected 
to the access network device via at least first and second 
communications links comprising a number of channels and 
to a network, comprising the steps of: 
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10 



15 



20 



. receiving a command from said network interface 
device to commence processing an incoming call at said 
access network device; 

assigning one of said channels for processing said 

incomizag call; 

transmitting a request to said sxabscriber unit from 
said access network device to process said incoming call; 

receiving an indication at said access network device 
of an outgoing call being initiated by said subscriber 
unit at substantially the same time as said request is 
trauismitted; 

notifying said subscriber unit of said channel 
assigned to said incoming call to process said incoming 
call in lieu of said outgoing call; and 

transmitting a ring trip command signdl to said 
network interface device to process said incoming call. 



12. A method of processing calls transmitted between a 
subscriber unit, an access network device connected to the 
subscriber unit, and a network interface device connected 
to the access network device via at least first and second 
. communications links comprising a number of channels and 
to a network, con?jrising the steps of: 

receiving an indication of an off -hook condition of 
25 said subscriber unit at said access network device; 

assigning one of said channels for said call using 
said access netwrk device; 

transniitting an outgoing call set-up command signal 
to said network interface device from said access network 
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device to commence establishing an outgoing call using 
said channel assigned by said access network device; 

receivixig a command signal from said network access 
device to said access network device to process cui 
5 incoming call from said network to said subscriber unit at 
s\2bstantially the same time as said outgoing call set'-up 
command is transmitted; and 

processing said incoming call as an outgoing call at 
said network interface device using said chaucmel. 

10 

13. A telecommunications system comprising: 
a subscriber unit; 

an access network device connected to said siabscriber 

unit ; 

15 a network interface device connected to the access 

network device via at least first, second and third 
communications links and to a network, said first, second 
and third communications links each comprising a number of 
channels, at least one of said channels on each of said 

20 first, second and third communication links being 
designated as a control channel for common chaxlnel 
signaling, each of said control channels being used 
siraultcuieously for controlling, respectively, said first, 
second and third communication links; 

25 wherein said access network device is programmable to 

assign said channels to calls initiated by at least one of 
said subscriber unit and said network interface device 
and, upon detection of failure in said first communication 
link, to move calls being processed on said channels on 
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said first communication link to said channels on said 
second and third communication links, said control 
channels on ^aid second and third communication links both 
continuing to operate simultaneously to provide common 
5 channel signaling. 



10 



25 



14 



A method of establishing a communication link between 
an access network device and a network interface device, 
the access network device being connected to at least one 
subscriber unit, the network interface device being 
connected to a network, the link comprising a number of 
channels, at least one if said channels being useful for 
common channel signaling, the method conqprising the steps 
of: 

15 transmitting a command to commence link 

initialization on said link from said access network 
device to said network interface device, said command 
con?,rising a signature variable having a value 
corresponding to a first counter operated by said access 

20 network device; 

transmitting a command to commence link 
initialization on said link from said network interface 
device to said access network device, said command 
comprising said signature variable having a value 
corresponding to a second counter operated by said network 

interface device; 

incrementing said first counter if a initialization 
request acknowledgment signal is not received from said 
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network interface device before a first timer operated byi 
eaid access network device reaches a predetermined value; : 
incrementing said second transmit counter if a 
initialization request acknowledgment signal is not ^ 
5 received from said access network device before a second 
timer operated by said network interface device reaches a 
predetermined value; 

receiving first and second acknowledgment signals at 
said access network device from said network, interface 
10 device; 

comparing said signature variable in said first and 
second acknowledgment signals to determine if said 
signature variable in each is the same; 

setting a first flag, if said signature variable in 
15 said first and second acknowledgment signals is the same, 
and providing an indication that said first flag is set in 
the next said acknowledgment signal transmitted to said 
network interface device; 

receiving third and fourth acknowledgment signals at 
20 said network interface device from said access network 
device ; 

comparing said signature variable in said third and 
fourth acknowledgment signals to determine if said 
signature variable in each is the same; and 
25 setting a second flag if said signature variable in 

said third and fourth acknowledgment signals are the same, 
and providing an indication that said second flag is set 
in the next said acknowledgment signal transmitted to said 
access network device. 
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15. A method as claimed in 
the step of' transmitting a 
communication link from said 
5 said access network device 
flags are set. 



claim 14, further comprising 
command to configure said 
network interface device to 
when said first and second 
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